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Partial Unindexing in FileMaker 


By Joe Kroeger & Mike Harris 

One of the defining characteristics of FileMaker has 
always been full indexing. That is, FileMaker auto¬ 
matically indexes all words and numbers and dates 
and times in all fields that accomodate the data types. 
This approach allows the program to build one big 
master index covering all fields. Much of FileMaker’s 
internal structure is derived from this big index and 
it is heavily integrated into the engine that is the heart 
of FileMaker. f 

The advantages of such indexing, compared to 
other approaches, has been (a) quick responses for 
all database operations that can use indexing, and (b) 
no active user setup involvement needed since in¬ 
dexing is automatic and non-optional. (Many data¬ 
base programs require users to define explicitly 
which fields are to be indexed.) 

Disadvantages of this indexing characteristic 
include (a) often slower data entry, especially for 


imported records, and (b) larger resulting files since 
the index consumes space. 

Many users, including your authors, have wished 
for years for an option that would allow a FileMaker 
file not to index all entries automatically. This would 
be useful in several circumstances. For example, 
when a subset of addresses is being extracted from 
several master address files in order to print mailing 
labels, it would often be nice if the import was faster 
and if the subset file was smaller. Indexing would 
normally not be needed in such a case since only 
printing will be done. 

The difficulty is that indexing is so deeply in¬ 
grained within the FileMaker program that turning it 
off, especially selectively field-by-field, is pretty much 
impossible for Claris to do, at least in the present 
incarnation. 

Is there a workaround? Partially, yes. In a recent 
issue of the Claris Techlnfo Journal there was a hint, 
in an article about something else, that led us to try 
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an experiment. It 
turns out that fields 
designated as nu¬ 
meric do not index 
non-numeric infor¬ 
mation! Simple, but 
does it really work? 

In the case of the 
address example 
mentioned earlier, 
what would happen 
if the various fields 
that make up the 
address were simply 
changed from text to 
numeric? We made 
two test files, one 
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with all the fields as 

text fields (Figure 1) and another with all the 
fields except the ZIP field as numeric (Figure 
2). (We might want to sort by ZIP codes, and 
anyway one always wants to store Zips as text 
since otherwise leading zeros are dropped by 
FileMaker.) We then imported the same 4,160 
addresses into each file and compressed both. 

Results: (a) the import process took 5 min¬ 
utes 9 seconds for 


Conclusion: Unindexing provides worth¬ 
while gains in time and size that will prove 
helpful in some situations. The price paid in 
return is the loss of some normal functionality. 


Figure 1 


Characteristics 

• It was a little strange to examine the index 
in the Index Test 2 file. Non-numeric characters Figure 2 


the fully indexed file 
and 3 minutes 7 
seconds for the par¬ 
tially indexed file, 
about 60% of the 
“normal” time; (b) 
the fully indexed file 
takes up 686 KBytes 
and the partially 
indexed file only 466 
KBytes, about 68% 
of the size. (By the 
way, the compres¬ 
sion times were also 
significantly shorter 
for the partially 
indexed file.) 
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characters present are consequently concate¬ 
nated. Figure 3 shows an example: in the nu¬ 
meric Street field the entered data in the figure 
is indexed as only “123456”, as shown in the 
View Index window. 

• Non-numeric characters in a partially 
indexed file, while not indexed, are still avail¬ 
able for browsing and for printing. But Finds 
that include alphabetic information will fail. 
Finds with numerals follow normal numeric 
rules, but are different than in text fields — 
Finding “12”, for example will not produce a 
record that contains “123”. A Sort also ignores 
the alphabetic characters. Finds and Sorts are 


accomplished based on the index, not the val¬ 
ues in the field. 

• We made a copy of the partially-indexed 
file and redefined the Street field as a text field. 
Good old FileMaker, unlike some databases, 
gracefully accepted the change, took a few 
second to re-index the field, and was ready to 
go again without disturbing the existing data. 
The file was a little bigger — in between the 
other two — as would be expected. 


FileMaker Indexing 

Indexing is a means of defining ahead of time where the value in a field is positioned with respect to the spec¬ 
trum of other values in that field in the rest of the file. The purpose of indexing is to make Sorting and Finding 
operations much quicker. When doing, for example, a Find on an indexed field, the program need not search 
through all records individually to locate occurances of the object of the Find. Instead, the index tells the pro¬ 
gram where the instances are located. You can demonstrate the result within FileMaker by doing aFind for emp¬ 
ty occurances (no data) in a field and then doing a Find for a non-empty value. Empty fields are not indexed so 
locating empty fields is much slower since FileMaker must search through all records. 

Two other basic database design approaches to indexing are (a) explicit partial indexing, where the user spec¬ 
ifies which fields are to be indexed, and (b) no indexing at all. Panorama— a quite capable database — does no 
indexing but instead simply loads the whole database into RAM where Finds and Sorts are so fast that it does not 
matter that all records must be searched. . 
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Transfering Multiple Invoice Data to Checks 


By Dave Brown 

I have a client who sells and installs doors and 
windows. Most of the purchase orders he issues 
go to a small number of vendors from whom 
he buys frequently each month. 

When the payables clerk pays invoices 
from one of the vendors, she frequently pays 
several invoices with a single check. It is desir¬ 
able to let the vendor know which invoices are 
being paid. It helps to keep accounts straight 
and saves a lot of unnecessary queries. 

Problem: How to make Filemaker Pro 
show multiple Invoice Numbers and the corre¬ 
sponding amounts on the check, and to get the 
check totalled correctly. 

The client uses a pre-printed check which 
is a tractor-fed multipart form, printed on a 
networked Imagewriter II. The layout for the 
check is in a separate Filemaker file called 
Checks, which is based on the MakeChecks™ 
template designed by Kim Hunter at Acrobytes 
Software. 1 

Under the present system, the clerk must 
go into the purchase order file and select the 
vendor invoices to be paid. The clerk then goes 
into the check layout and manually types each 
invoice number and each invoice amount into 
repeating fields. This works fairly well, though 
it is quite time consuming and is subject to 
error. While this is a firm that does not do a lot 
of volume, the amounts on the invoices are 
frequently in four figures or more. Therefore 
keeping on top of the invoices to make sure 
that discounts are properly taken when they are 
due is an important task. 

1 MakeChecks may be purchased from Acrobyte 
Software at 714-768-8490 or from The FileMaker 
Annex at 408-761-3987. 


But Filemaker cannot import non-repeat¬ 
ing data into repeating fields. So once a group 
of purchase orders to be paid for a single ven¬ 
dor has been selected, it is difficult to devise a 
way to conveniently accomplish the transfer of 
this information to the Checks file. 

I went back to Acrobytes and after a little 
discussion decided to use their software called 
MakeRepeats+™. Make Repeats is a program 
that gathers information from a text file, and 
rearranges it so that it can be imported into 
| repeating fields. I can create a text file of the 

data to be paid, modify the file, and import 
| repeating versions right into the Checks file. 

First, the payables clerk Finds the invoices 
to be paid. The Find is usually by Vendor 
| name and then, using a Tag field, each of that 

selected Vendor’s items is designated. Then 
another Find is made on the Tag field’s check 
mark. (Incidentally, I put a button on the lay- 

I 

out that automatically clears the Tag fields, 
using a script that Replaces the contents of the 
Tag field with blanks. That makes the Tag field 
ready for the next use with minimum effort.) 

I placed a button on the Purchase and 
Payables layout which invokes a script that 
exports only the Vendor ID Num, the Vendor 
Invoice Num, and the Balance Due on that 
invoice. These three fields are exported from 
| Filemaker as tab-separated text into a file called 
P&P Checks (the name used is arbitrary). 

| 

The clerk then invokes the operation of 
MakeRepeats+ using a QuicKeys macro. 

| MakeRepeats+ resides as a desk accessory in 
| the Apple Menu, and is thus easily accessed. 

The sequence in QuicKeys was recorded as we 
1 manually proceeded through the business of 
having MakeRepeats+ select the P&P Checks 
document, convert it to Repeats P&P Checks, 
and then quit MakeRepeats+. 

The process then shifts to the Checks file. 
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On the check form a button/script combina¬ 
tion imports Repeats P&P Checks into the file, f 
where all the data end up in the desired repeat- | 

ing fields, with one check per vendor. Problem 
solved! j 

Sidelights 

There are a couple of important points to 
be aware of Every time you use this procedure, | 
the P&P Checks file is replaced with new infer- | 
mation, as is Repeats P&P Checks. As long as 
these text documents and MakeRepeats+ are 
inside the same folder as the Purchase & Pay¬ 
ables and Checks FileMaker files, no typing or 
naming of files is necessary. The software sim¬ 
ply replaces these text files with updated infer- | 

mation every time the Macro is invoked. 

Another point is that MakeRepeats+ uses 
Vendor ID Num as a key. Each of the records 
in Purchases and Payables must have that key 
field read exactly the same way. There can be 
no mixing of upper and lower case in one 
record and all caps in another. Even the use of 
a carriage return (which is not visible), will 
mess up the procedure. Therefore special care 

.j 

must be taken to be sure that all vendor codes 
are always entered exactly the same way. We 
have chosen all caps for the three- or four- 
character vendor codes. 

When the script that imports the text does 
its work, it also does relookups on the Vendor 
ID Num, and on the Balance Due field. Both 
fields generate additional information. A look¬ 
up on Vendor ID Num brings into the the 
check the name, address, city and state of the 
payee. A lookup on the Balance Due field 
brings in the text form of the amount to be 
paid which will be printed on the check, and it 
also triggers the calculation that sums the total 
of the check. Converting the numerical total of 
the check into text for the payment amount 
line on the check is generated from calculation 
routines imbedded in the Filemaker Checks 
file, which is based on Acrobytes MakeChecks 


template. 

Incidentally, the procedure also handles 
credit amounts, so that a negative credit memo 
can be applied against the total of the invoices 
being paid, and reduces the check amount 
correspondingly. It only needs to be entered 
properly into the Purchase and Payables file. 

Summary 

The procedure outline is (1) Find and tag 
the relevant records in the Purchase and Pay¬ 
ables master file, then Find the tagged records. 
(2) Click a button in Purchase and Payables 
that exports the tagged records to a text file. (3) 
Enter a keystroke that stimulates a QuicKeys 
macro to open MakeRepeats and cause it to 
massage the text file and create a new text file 
and then Quits MakeRepeats. (4) The opera¬ 
tor opens the Checks file and clicks a button 
that executes a FileMaker script that imports 
data from the massaged data in the text file. (5) 
The same script also executes two relookups. 

This solution uses a couple of buttons and 
one keystroke to transfer accurate information 
onto the check. It saves a lot of data entry, and 
makes sure that the check bears accurate infor¬ 
mation which the vendor will need to properly 

credit the account. . 

—V- 

Dave Brown is atdb associates in Kansas City, 
Missouri and does database consulting 
in the area. He can be reached by phone at 
816-453-7979 or on AOL at AAPRDWB. 
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Guarding Serial Numbers and Reserializing Too 


By Douglas Brown 

Serial numbers are fundamental building 
blocks and often critical components of robust 
file design. In fact, sometimes much of the 
functionality of an entire database rests square¬ 
ly on the shoulders of a serial number field, 
whose sole purpose is to maintain internal 
integrity for the data and records in the file. We 
designers define their uses and parameters and 
they often serve vital roles, so it pays to think 
about them. Ask any experienced FileMaker 
designer and they’ll tell you that a well-engi¬ 
neered, well-behaved serial number field is 
worth its weight in gold. 


Serial Number Importance 

Serial numbers are organizational work¬ 
horses — they appear on our layouts as simple 
record numbers, as concatenated account 
numbers, as sequential transaction numbers, as 
part numbers, as account numbers, as lookup 
keys, as log numbers, and so forth. They are 
indispensable for numerous types of internal 
processes, such as self-lookups or record-to- 
record and file-to-file information transfers or 
to generate sub-serials for manipulation of 
repeating fields. They are useful before and 
after imports, can be auto-updated and reseri¬ 
alized, and can even be used for numbering 
records by category in subsummary reports 1 . 
The current FileMaker program provides capa¬ 
ble and versatile facilities for creating a wide 
range of serial number field types. 

FileMaker allows us to import records 
from external sources, including other File¬ 
Maker files. Such imported records may or 


1 This last example is available as a Techlnfo Brief 
from the Claris faxback answerline: 800-800-8954. 


may not contain serial numbers. When a desti¬ 
nation file requires serial numbers for import¬ 
ed records, FileMaker provides the quite 
valuable Reserialize command (accessed via 
the Replace dialog) that can also be incorpo¬ 
rated in scripts. But there are situations where 
getting a set of new records reserialized proper¬ 
ly poses an interesting challenge. 

Problem Example 

Perhaps you have run across a situation 
like this one. There is a FileMaker database that 
requires a unique identifier for each record. 

For reasons based on the database design, this 
is a mandatory record attribute. Suppose as 
well that the identifier needs to be permanent 
— freeze-dried upon creation and locked in a 
carefully-constructed, password-protected, 
permafrost. And once an identifier has been 
used it must never be allowed to live again in 
the file. If the record is deleted, the assigned 
serial number for that record must become 
history. Duplicate such a record and a fresh 
new serial number results. Delete such a record 
and it’s “Farewell fair serial!” And the only gaps 
in the serial sequence will be those for deleted 
records. 

Thus each serial number is Required, 
Unique, Sequential, and Not Modifiable. This 
type of field is easy to include in Filemaker, and 
works fine for records that are manually en¬ 
tered into the file. Proper selection of field 
definition options (Figure 1) creates an auto- 
entered, sequentially-incremented, verified-as- 
unique, unmodifiable, serial number in each 
new record. Passwords can be defined — for 
certain layouts or even for a whole file — to 
lock things up as tightly as maybe desired. 

But what if we want to create a script that 
imports records into this file and then reserial¬ 
izes the newly-introduced records? A major 


Page 6 • Issue 60 • ©1994 Elk Horn Publishing • The FileMaker Report 








Entry Options for Number Field “SerialNum” 
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□ Look up ualues from a file: [ Set Lookup... ] 


[ Cancel 


GO 


Figure 1 problem is quickly discovered: when the script 

is executed, FileMaker will not allow reserial¬ 
ization of the imported records. This is because 
the serial number field in the database has been 
defined to “Prohibit modification of auto- 
entered values”. We have bumped into a con¬ 
flict between the need to reserialize imported 
records so they fit into an existing serialization 
scheme, and the need to prevent tampering 
with any serial numbers in the file. 

In other words, you can write a script that 
will import records from a specified file with a 
preset import order, but if “Prohibit modifica¬ 
tion. .. ” has been specified for the serial num¬ 
ber field, the script will not be able to complete 
the Reserialize command and the imported 
serial numbers will remain untouched. The file 
will then no longer meet the original require¬ 
ment of having truly sequential serial numbers. 

Potential Solutions 

It would be possible to enter the Define 
Fields mode before or after an import, tempo¬ 
rarily change the field definition, modify the 
serial numbers (being very careful about such 


things as exactly 
which records 
are changed, 
what values are 
used, and updat¬ 
ing the“next 
value” defini¬ 
tion), and then 
re-redefine the 
serial field back 
to the protected 
state. This pro¬ 
cess is not only 
fraught with 
opportunities 
for error, but if 
imports are 
executed on a 
regular basis it 
both multiplies those opportunities and be¬ 
comes a proverbial pain. 

Okay, so why not try sorting and reserializ¬ 
ing the records to be imported prior to the 
import? We will, of course, need to reserialize 
the records to be imported starting from the 
next number past the last record in the destina¬ 
tion database. This means the external source 
files needs to have a serial number field and 
that we need to have password clearance for 
reserialization. It also means that we need to 
update the destination file’s “next value” to 
exactly account for the imported records. 

This is very awkward: It is necessary to 
open up the field definition and adjust (care¬ 
fully!) the next serial number for the number of 
records to be imported. Otherwise, a new 
record generated within the file after the im¬ 
port would duplicate the serial number of one 
of the imported records. An error message 
would arrive and a user without password 
access who is prohibited from overriding data 
entry warnings or changing field definitions (a 
quite likely circumstance) will be unable to 
proceed: the file will not be usable. This is obvi- 
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uosly not a good solution. 

What is needed is a way to keep the serial 
number field available for reserialization by a 
script, yet at the same time not available to be 
edited. A potentially workable way to accom¬ 
plish this is: I 

(a) remove the restriction preventing modifi¬ 
cation of the serial number field; 

(b) add a “pre-defined value list” option with 
the value list empty; 

(c) format the field on the layout as a pop-up 
menu; 

(d) protect the layout from being modified. 

1 

This neat trick prevents users from altering 
the serial number data in Browse mode — any 
attempt to click or tab into the field just results 
in an empty pop-up menu. A scripted reserial¬ 
ization, however, does work. (You may want to 
password-prevent creation of new scripts.) 

The difficulty is that a field formatted in 
this way is restricted in its ability to accept Find 
requests and is difficult to copy values from—a 
“no values defined” flag keeps popping up 
when the field is clicked. (Nonetheless, in other 
situations this trick is a nice one to remember.) 

| 

One Workable Solution 

What we want for our purposes is a solid, 
permanent serial number field that can be 
actively reserialized after an import and easily 
used in Browse and Find, without jumping 
through hoops and/or risking modification of 
the serial value or serialization order. Filemaker 
is so flexible there are usually many solutions to 

any problem and while I can’t claim the follow- 1 

| 

ing is definitive, if handled with care it does at 

least provide one relatively secure solution that 

does not require alteration of field definitions 

as part of an operating procedure. 

We’ll begin with the serial number in the 

master database. Let’s call the field Root Serial 

— 

and let’s be quite sure that no other database 
we might import from contains a field with this 
particular name. (Naming it •RootSerial* or 


RootSSerial or otherwise making use of special 
characters may help keep the name unique.) 
Root_Serial is defined as a numeric, auto- 
entered, incremented serial number, but does 
not have the “prohibit modification” option 
assigned to it. 

Don’t panic; Root_Serial will not be used 
as the visible serial number for the records. 
Instead we will create another field, a calcula¬ 
tion field named VisableSerial. This field will 
contain the visible serial number the user will 
see. A calculation field, as you may recall, dis¬ 
plays data, yet remains unalterable; if tabbed or 
clicked into accidentally, it will display an error 
message if any sort of alteration or deletion is 
attempted. The VisableSerial field also re¬ 
mains available for manual or scripted copy¬ 
ing, can accept a pasted or typed value in Find 
mode, can be used as a lookup key, plus we can 
easily export records that include VisableSerial. 
The calculated serial number can also, if re¬ 
quired, include a concatenated value from 
another field or can participate in the calcula¬ 
tion of a separate concatenated value. And 
notice that since it is a calculation field, users 
cannot directly import into it. 

For this arrangement to be of any signifi¬ 
cant value, Root_Serial should never be (or 
appear to be) directly accessible on any layout. 
If it is, you might inadvertently click or tab into 
it and possibly accidentally alter it. This is 
something we want definitely to avoid. 

So how do we hide Root_Serial yet keep it 
available to our import/reserialize script? To 
reserialize a field via a script, the field in ques¬ 
tion must be on the current layout. But if it is 
on the layout, might it not be vulnerable, alter¬ 
able and so on? What to do? 

One standard trick is to format the text 
color of the field as white (on a white back¬ 
ground), remove it from the tab order, then 
hide it behind another field or behind a graph¬ 
ic. In the situation currently under discussion, 
we could tuck Root_Serial neatly behind the 
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VisableSerial calculation field. (Use the Align 
Objects and Send to Back commands.) 

I 

For even more security, we might also | 

select both the front-most field VisableSerial 
and the (now invisible) sent-to-back 
Root_Serial (by using the mouse and dragging 
a wide area around both fields so that both are 
selected) and then define the pair as a group. 

Why? Well, if in the future you or a user 
needed to copy and paste VisableSerial to a 
new layout in the current database, both fields 
would travel nicely together. (Root_Serial will 
be in what could be described as ‘piggyback 
stealth mode’.) In this way it will be very diffi¬ 
cult to alter Root_Serial or VisableSerial with 
the user in Browse mode. Root_Serial will 
nevertheless remain on the layout, invisible to 
you but available to scripts for reserialization. 

The grouping also means that someone mov¬ 
ing fields around on the layout will not easily 
uncover Root_Serial. 

In some cases, it might be better to place 
Root_Serial only once in a database, on only 
one layout, accessible only by scripts or pass¬ 
words or a combination of both. Point is: the 
harder Root_Serial is to get at, the less likely 
you or your users will accidentally alter this all 
important field. 

A script that needs to reserialize can switch 
to the layout where Root_Serial lives, do its 
job, and switch back. The degree of security 
required will depend on the specific system you 
are implementing. I strongly advise careful 
thought on the precise use of passwords and 
how user activities are restricted. 

No matter what you do with Root_Serial, 
it is a good idea to remove it from the tab se¬ 
quence on any layout where it lives. After exe¬ 
cuting the Tab Order command, instead of 
just changing the tab number, delete it. You’ll 
get a warning when you try to close the tab 
dialog, but if you accept it, you’ll no longer be 
able to tab into the field. 


Calculating VisableSerial 

Now to return to the formula for the calcu¬ 
lation of the visible serial number. It could be 
as simple as: 

VisableSerial = Root_Seria! 

One could, of course, get fancier, as in: 

VisableSerial = {text result) 

If (Root_Serial > 1, Root_Serial, 

"ERROR - DUPLICATE THIS RECORD,THEN COME 
BACK AND DELETE.") 

(With a text result, the Find characteristics are 
a little different.) 

Note that, since Root_Serial is defined as a 
modifiable serial number field, a scripted im¬ 
port can reserialize imported records. The 
script, after the import, would select Root_Serial 
via a Go to Field command and then immedi¬ 
ate Reserialize. The visible serial number for 
the newly imported records, that is, the field 
named VisableSerial, would also be updated; it 
would pass the initial If condition test 

"If (Root_Serial > 1,..." 

and thus return the newly reserialized sequen¬ 
tial number value to the VisableSerial field. In 
that way, each imported record would have a 
visible yet not modifiable newly updated se¬ 
quential serial number. 

But, ah-ha!, what if someone imported 
without using our script? Alas, the newly im¬ 
ported records would not contain accurate 
serial numbers. But don’t despair, the calcula¬ 
tion formula above does double duty: it not 
only flags improperly imported records but 
suggests a solution for the user, namely: dupli¬ 
cate this record (which gives it a new, proper 
serial number) and then go back and delete the 
originally imported record with the error mes¬ 
sage in it. Not terribly elegant, but at least one 
way to catch problem imports. 

One could, of course, design a script or 
button that reserializes the found set after a 
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manual import, but that could be a problem. It 
provides the user with the power to reserialize 
the entire database, or an incorrect found set. It 
seems best to restrict all imports into the Master 
file as a VSO (via script only). This way, we 
retain control. 

The script for such imports is simple 
enough and looks something like this: 

Enter Browse Mode [] 

Go to Layout ["Import Layout"] 

Import Records [Restore, "import.FM"] 

Go to Field [Select/play," Root_serial"] 
Reserialized 

Note, I trust not to your horror, that the 
import file named in this script has the DOS 
extension “.FM” as part of the file name. This 
was done simply to remind us that Filemaker 
Pro for Windows requires the name extension. 
For folks into cross-platforming, we can’t for¬ 
get to remember that all file names, including 
names imbedded in scripts, must conform to 
standard DOS conventions in order to perform 
accurately on the PC. 


Also note that Reserialize doe not have the 
“No Dialog” option attached. If you are de¬ 
signing files for your own use, you may prefer 
the option of reserializing or not. If you are 
scripting for others you may want to include 
“No Dialog” since otherwise the user can can¬ 
cel reserialization and will be left with record 
serial numbers likely out of whack and not 
easily fixed. 

As usual, when using any design technique 
such as this one, be sure to check it out for 
yourself on a clone database using expendable 
data and only incorporate in a working file 
when you are completely satisfied. 

Douglas Brown is president of 
Douglas F. Brown Software Services Inc., 
a Canadian corporation that provides 
software solutions to the legal and 
entertainment professions, and small 
businesses in Ontario, Canada. 
He may be reached at 416-590-9081. 


Removing Empty Repeating Field Lines 


By Joe Kroeger 

£ I have a new project that requires me to 
eliminate some sets of empty repeating field 
lines that exist in the midst of other 
lines of data. I’ve been unable to find 
a convenient way to do so. I prefer 
not having to export, manipulate, 
and then import the data, if possible. 

Figure 1 shows the situation. Can 
you suggest a method? - B. T. 


one technique is suggested in the article about 
data stacks in issue #35. Unfortunately, it is not 
fully elaborated there. But if you get the idea of 
a serial number for each line of a repeating field 


Figure 1 


J/5 There are several ways to handle 
the elimination of blank lines in 
repeating fields. The background for 
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that is unique in the whole data file, you will be 
most of the way there. Extracting individual 
repeating lines with calculations then allows a 
relookup based on repeating line serial num¬ 
bers to reassemble the repeating lines minus 
the blanks. 

In your case the answer may be even easier 
and may depend on the goal to be accom¬ 
plished. For example, for printing reports, 
simply sliding on the layout will collapse blank 
spaces and you may not need to remove them. 

Scripting an Answer 

Alternatively, with today’s scripting capa¬ 
bilities, I would start by trying to build a script 
that simply cuts and pastes data from one line 

"Move 4 -> 3" 


♦ Enter Browse Mode [] 

♦ Go to Layout ["Rpt Layout"] 

* Cut [Select, "Field A "-4] 

* Paste [Select, No style, "Field A "-3] 

* Cut [Select, "Field B"-4] 

♦ Paste [Select, No style, "Field B"-3] 


Figure 4 


"Move 3 -> 2" 


* Enter Browse Mode [] 

* Go to Layout ["Rpt Layout"] 

* Cut [Select, "Field A "-3] 

* Paste [Select, No style, "Field A"-2] 

* Cut [Select, "Field B "-3] 

* Paste [Select, No style, "Field B "-2] 

* Perform Script [Sub-scripts, "Move 4 -> 3"] 


iMSili into another. It might take several 
H scripts — one for each empty repeat- 
11 ing line location — but each script 
|| should be able to work on several 

parallel repeating fields. I would put 
|| a little button at the end of each re- 
|| peating line and associate a script 

|| with each button. (Figure 2) You 

_ ft may save some work by chaining 

some scripts together. There is a lot 
less overhead with this approach, at 
least in terms of database structure. 

An example script is shown in Figure 3. 
This approach will be effective for only one 
record at a time. Since this may also be the way 
that the blanks are encountered, there may not 
be a problem. Notice that when there are two 
parallel repeating fields, it is possible for one 
line to be non-empty while the other is empty. 
In such a case, this script depends on visual 
inspection by the operator to make sure that 
valuable information is not wiped out. 

On the other hand, when the operator 
knows which line should be eliminated, it is 
not necessary to make them blank first—just 
push the button and the line is gone. 

Figure 3 shows the script for moving line 
four up to line three. It stands alone. Figure 4 
shows the script for the next line up for moving 
three to two. It executes the script in Figure 3 to 
pull line four up after line three has been moved. 
This sequencing of scripts saves time when 
writing a script for each button on the layout. 

Note that these kinds of scripts/buttons are 
dangerous since they can wipe out data if acci¬ 
dently exercised. I suggest that you make a 
separate password-protected layout where the 
buttons live so that ordinary editing and data 
entry is done on a layout that does not contain 
them. In some cases it will be valuable to add a 
step at the end of the script that switches back 
to the editing layout where the buttons are no 
longer available. 
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Q&A: Scripting a Database Subset 


By Joe Kroeger 

1 

1 

Is there a simple way to create a subset of a 
FileMaker database? I am often faced with with 
Finding a set of, say, 100 records out of a cou¬ 
ple of thousand, then making a clone, opening 
the clone, importing the found set, closing the 
clone, and deleting the set from the original 
file. These are straightforward operations but it 
would be nice to have it all automated. I’ve 
been using an external macro generator for 
portions, but would prefer for it to be 100% 
FileMaker. Can a script do this work? — T. T. 

ft I agree that this seems like a task that 
ought to be scriptable within FileMaker. So I 
tried it. The sequence of events you outlined in 
your question after finding the desired set of 
records, is what I attempted to put in the script. 

First I created a database called Test con¬ 
taining a single numeric field. I entered 50 
simple records containing the numbers 1 
through 50 (so it would be easier to follow the 
results). Then I set out 
to create a script, which 
I called Make Subset. I 
entered the first few 
script steps as shown in 
Figure 1. The Sort step 
is not necessary if you 
don’t need it. 

Once the step creat¬ 
ing the clone was gener¬ 
ated, I needed a way to 
import into the clone 
the found set of records 
from Test. I realized 
that this means there 
needs to be a script in 
the clone file that can be 
triggered by the script 


in the Test file to accomplish the Import. In 
turn, this means that the script that does the 
importing needs to already exist in the Test file 
before the clone is created so that it will show 
up in the clone file. 

I defined the import script, calling it ‘Into 
Clone. See Figure 2. (I like to use a bullet as the 
starting character of scripts that are only used 
by other scripts or buttons.) 

I was concerned that there would be some 
confusion about the Close command since it 
might not be definable within the same file. It 
turns out, however, that by just leaving the file 
unspecified, FileMaker closes the current file — 
just what we want to happen. 

Depending on the particular circumstances 
being implemented, it might be necessary to 
create the clone, update the scripts in the clone, 
then throw away the original file and rename 
the clone so it becomes the master file. 

Once 'Into Clone exists, then the Make 
Subset script can be expanded. In order to do 
so, the clone file must already exist in the folder 
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Unto Clone' 


♦ Enter Browse Mode [] 

♦ Go to Layout ["Edit Layout"] 

♦ Import Records [Restore, No dialog, "Q&A Test"] 

♦ Close [] 


m 


Options. 

[X] Restore import order 
fX] Perform without dialog 


Mi 


Specify File... 


"Make Subset" 


♦ Enter Browse Mode [] 


♦ Go to Layout ["Edit Layout"] 


♦ Sort [Restore, No dialog] 


♦ Save a Copy as ["Clone of Q&A Test"] 


Perform *Cfon« of Q&A T*s 


♦ Delete Found Set [j 

o 


Options ■ 


Perform sub-scripts Specify : | External Script... 


™ with Test. (This is easy to do by either making 

one manually using the same name as in the 
“■ Make Subset script, or by executing the in¬ 

complete script shown in Figure 1.) Figure 3 
shows the addition of the step that executes the 
•Into Clone script in the clone file. When the 
“external sub-script” option is selected, first 
the external file is specified (the clone file) and 
then a script within that file is specified. 

The final step in Make Subset is to delete 
| the found set in Test. I think it is smart to in¬ 
clude the warning dialog about the delete. 

The script works well. Chalk up another 
one for FileMaker! 


ro 

K 

3 

o> 


Notes 

If the original Find used to get the subset of 
records is repetitive, then it, too, can be includ¬ 
ed early in the script. Simply execute the Find 
once, then cause it to be restored in a Find step 
in the Make Subset script. 

Given the way the scripts are set up, it is 
possible for the clone file itself to perform the 
same operation, once it has been renamed. 

-V* 


Techniques, Tips, & Notes 


ByJoe Kroeger 

Newsletter Changes 

The FileMaker Report is being revised, 
starting with the next issue. Enclosed is a letter 
of explanation with all the details. You won’t 
see much difference here in the newsletter 
itself. Same types of topics, same type of writ¬ 
ing. We’ll continue to address FileMaker issues 
of concern to those users who create and mod¬ 
ify FileMaker databases. The big differences 
will be lower subscription rates and shorter 


intervals between issues. There will be an opin¬ 
ionated but brief editorial once in a while and 
brief reviews. 

Lower Priced FileMaker 

Claris has announced that FileMaker Pro 
2.1 for Macintosh is now available for a pro¬ 
motional price of $99 in the U.S. and $149 in 
Canada until December 31 this year. If you are 
contemplating putting more users in your 
organization on FileMaker, this may be a good 
time to stock up. It is also an opportunity to get 
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registered versions for all those “borrowed” 
copies that may have popped up. It appears 
that mail order suppliers are selling it at the 
prices Claris announced and not discounted 
further. 

New FileMaker Products 

Claris has recently announced two new 
FileMaker programs: the FileMaker Pro Solu¬ 
tions Development Kit and FileMaker Pro 
Server. The S D Kit is aimed at third party de¬ 
velopers who want a FileMaker Run-Time 
program to distribute with their templates. The 
Server version of FileMaker is designed to im¬ 
prove performance in a multiuser networked 
environment. FM Server helps minimize net¬ 
work traffic and so is most effective when there 
are lots of users crowding the network. More 
later. 

Apology 

Unfortunately, a different version of the 
article “Creating Even Multiple Columns” 
from issue #58 has evidently appeared in an¬ 
other publication. We try to keep everything 
here in the newsletter original material. Once 
in a while there maybe a reprint of something 
from another source and we are careful to label 
it as such. Once in a while another publication 
asks permission to reprint something from this 
newsletter and we often give permission. But 
the article from #58 was submitted in parallel to 
two periodicals and got accepted at both. I’m 
sorry it happened. 

Faster Finds in Empty Fields 

It has become clear lately that it is time to 
renew an old tip from several years ago in these 
columns. Is there a way to speed up a Find that 
includes an empty field? FileMaker, as we know, 
automatically indexes all basic characters ex¬ 
cept punctuation, special characters, and lack 
ofc haracters. Since emptiness is not indexed, it 
takes FileMaker a long time to locate those 


records that have nothing in the designated 
field (using the special Find character “=”). On 
large databases especially, it can be excruciat¬ 
ingly slow to Find with an empty field. 

If you need to do repetitive Finds that 
include an empty field, it will often pay to sim¬ 
ply give FileMaker non-emptiness to index. I 
often enter “mt” (Get it? Empty = mt.) or “z” 
in fields that contain no data. It is easy to just 
Replace into already empty fields whatever 
character or characters you elect to use. Don’t 
use punctuation or special non-indexed char¬ 
acters, but do use something unique. 

Sometimes I auto-enter “mt” into appro¬ 
priate fields when creating new records. “Mt” 
can be overwritten whenever real data is en¬ 
tered. When finding an empty field that con¬ 
tains “mt” I suggest that you use “=mt” in the 
Find request in order to avoid getting a word 
or phrase that starts with the letters “mt”. 

An Almost Lost Tip 

At the end of the article in issue #59 about 
Scripting Repeating Fields, I threw in a related 
tip about creating custom warning messages. I 
seem to have put it in the wrong place — some 
readers remember glancing at it but then have 
not been able to locate it again. And a couple of 
subscribers passed it over altogether since they 
were not interested in the scripting article. 

The issue that arises is that FileMaker scripts 
are now capable of not only doing considerable 
work, but also wreaking considerable havoc. 
Valuable data can be destroyed if a script is 
triggered accidently. Hiding a dangerous script 
so it does not appear in the Scripts menu is a 
good step. 

Another technique to help prevent mis¬ 
haps is to build a custom warning dialog box, 
providing an escape mechanism for an acci¬ 
dently-triggered script. Let the script take the 
user to a dedicated layout that contains an alert 
message (Sample: “This script modifies data in 
all the records of the currently found set. Do 
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you really want to do this?”), and two buttons. 
A NO button triggers a new script that goes 
back to the starting layout and does nothing 
else. A YES button triggers a new script that 
proceeds to execute the dangerous operation. 


to get an AppleScript program to hum along 
properly in the background. Be warned that 
AppleScript is, unfortunately, not easy to use 
with FileMaker. (Claris needs some good doc¬ 
umentation about the FileMaker dictionary.) 


When 'Today' is Yesterday 

Is there is a way to have a formula that 
includes the Today function recalculate auto¬ 
matically when a new day is entered? If a ma¬ 
chine with such a calculation is left on through 
midnight, it does not change the result to re¬ 
flect the new day. I know of no way to cause 
FileMaker to automatically do an update like 
this. 

The ‘simple’ thing to do is to close and then 
open the file in question, perhaps just after 
midnight. But with manual intervention neces¬ 
sary it is not always easy to know if the file is in 
a valid state or not. 

With some new fields the validity status 
can be easily checked in a file where it other¬ 
wise takes a long time to recalculate Today. 

One field contains simply the Today function 
and so reflects the date the file was last opened. 
A second field responds to a button that exe¬ 
cutes a “Paste Current Date” command. Then, 
either visually or with a calculation in a third 
field, the two dates are compared in order to 
decide if the file should be closed and opened 
again. You might be able to include this infor¬ 
mation in a script, using it to, for example, go 
ahead and generate a report if all is well, or go 
to a layout that suggests the file be closed and 
then opened. 

You might create a script (that lives in a 
small separate file) to be used for generating 
any reports that include data that depends on 
Today. This auxiliary script can close the file in 
question, open it again, and then cause the 
report to be printed. 

Another approach is to try to use Apple- 
Script to trigger an event. AppleScript can 
access the system clock, but it may not be easy 


Easy Days 

If you want to know what day of the week is 
represented by a given date, you can build a 
calculation that extracts the name of the day 
from a date field. Fine. But a quickie way that 
will often work well is to simply format the date 
field (or a copy of the date field). If you have a 
date like 5/13/94, it already implies the day of 
the week and FileMaker includes a wide range 
of date formatting options, including some 
that show the week day. 



The figure above shows three versions of 
the same date field. Each is formatted different¬ 
ly. The top one is the raw date data as entered. 
The middle one is a copy of the same date field, 
but formatted (in Layout mode) using one of 
the standard date formats (from the Format 
menu). The bottom one is the same date field 
once again, this time formatted using a custom 
format. Nice. 

(The FileMaker date formatting is nicely 
done and unusually versatile. But if you don’t 
like the regular formats, the custom option 
allows you to build just what you like. And it 
remains easy to use like most of FileMaker.) 

-V* 
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